The first article in this series argued that governance needs memory. The next question is what should feed it and when an observation becomes a signal.

Governance produces information in many places. Linters report rule violations. Security scanners identify weaknesses. Architecture reviews document concerns. Teams request exceptions. Reviewers approve some deviations and reject others.

These records usually remain close to the process or tool that produced them. A finding stays in a pipeline log. A review decision remains in a ticket. The rationale for an exception is known to a small group of people until that group changes.

These fragments need to remain connected beyond their original tools and processes. Doing so requires a distinction between observations and signals, and between technical evidence and human judgement.

The principle extends beyond APIs

API design is only one application of a broader principle. Thilo Rottach made this point in a comment on my LinkedIn post about the first article.

The same considerations apply to static application security testing, security code reviews, architecture reviews, cloud usage reviews, and other forms of governance. Each compares an actual state with rules, guardrails, expectations, or professional judgement.

These activities repeat over time. That makes them more than a sequence of isolated controls.

One architecture review may reveal a local concern. Similar concerns across several systems may expose a weakness in the platform or in the architecture principles themselves.

One exception may be justified by a specific context. A growing number of similar exceptions may indicate that the underlying rule no longer fits the systems it is meant to govern.

Repeated reviews therefore create evidence not only about the governed systems, but also about the governance approach itself.

From lifecycle intelligence to governance evidence

In 2018, I wrote a German blogpost about Application Lifecycle Intelligence and the challenge of connecting data from version control, continuous integration, issue tracking, deployment pipelines, and application monitoring.

Each system provided only a partial view of software delivery. The broader picture emerged by connecting and interpreting their data.

Governance faces a similar fragmentation problem, but its inputs are more varied. They include machine-generated findings as well as reviews, exceptions, rationales, and decisions.

The task is therefore not only to aggregate data or calculate better metrics. Governance also must preserve how evidence was interpreted.

Technical sensors and human observation points

The term sensor is useful because it draws attention to the sources from which governance receives information. It should not imply that all relevant observations are automated or objective.

Technical sensors include API linting, static application security testing, dependency scanning, policy as code, architecture fitness functions, cloud policy checks, runtime telemetry, and audit events.

They provide structured and repeatable evidence, but their scope is defined by rules, thresholds, configuration, and available data. A linter evaluates an API against a particular ruleset. A scanner only reports what its detection logic can recognize.

Governance also relies on human observation points. Architecture reviews, security code reviews, API design reviews, risk assessments, and exception processes address situations that cannot be reduced completely to executable rules.

Human reviewers can consider context, trade-offs, and consequences. Their assessments also reflect experience, interpretation, organizational position, and the information available at the time.

Both sources are necessary, but they do not represent the same kind of evidence.

A scanner finding that a reviewer concern, and an approved exception have different meanings. Their source, status, and relationship therefore need to remain visible.

At minimum, the record should retain the artifact and version under review, the applicable control and its version, the source of the observation, the review or process in which it was considered, the resulting decision and rationale, and any later correction, expiration, or replacement.

From observation to signal

An observation records that something occurred. A signal suggests that the observation deserves broader attention.

The difference cannot be determined by frequency alone.

A naming violation across many API specifications may indicate an unclear guideline or a missing template. It may also be largely cosmetic and require no significant intervention.

A single security finding can be more important than hundreds of formal deviations if its potential impact is high enough.

Repeated exceptions may show that a policy is unrealistic. They may also show that teams have learned to bypass a necessary control.

Whether an observation becomes a signal depends on context:

recurrence across teams or systems
severity and potential consequence
the rule and its version
repeated decisions in comparable cases
changes in exception behavior
concentration within a technology or platform
actions taken after previous findings

Consider two teams that violate the same rule. For one team, the cause may be a misunderstanding. For the other, the required capability may not exist on the shared platform. The finding looks identical, but the appropriate response is different. Governance analytics therefore cannot stop at counting violations. It must connect observations with decisions and consequences.

A first relational model

A first implementation does not require an elaborate technical platform. A relational database can provide a sufficient foundation. The model might include:

Artifact
ArtifactVersion
Control
ControlVersion
Observation
ObservationSource
Review
Decision
Exception
Rationale
FeedbackAction

The important distinction is between what was observed, how it was reviewed, and what followed. Tool findings enter the model as observations. Reviews connect them with context and lead to decisions, exceptions, or follow-up actions. Those actions may affect a rule, a platform capability, a training offer, a template, or the review process itself.

The database does not have to be physically central. Governance information may remain in several systems if common identifiers and relationships allow it to be connected.

An organization should be able to trace a path from an observation to the decision it influenced and to the action that followed.

Closing the feedback loop

The value of this memory depends on whether retained evidence influences future rules, platforms, and decisions.

Recurring findings can reveal rules that are unclear, obsolete, or difficult to apply.

Patterns across teams can identify where enablement is needed. That does not only concern new joiners. Experienced professionals also work with changing platforms, standards, and regulatory expectations.

Repeated deviations can expose missing platform capabilities. In such a case, another guideline may achieve little. A secure default, reusable component, or supported Golden Path may be the more effective response.

Earlier decisions can also make future reviews more consistent. Comparable cases become visible, rationales can be challenged, and governance depends less on the personal memory of individual experts.

None of these responses should follow automatically from a dashboard.

A pattern provides a reason to investigate. The response may be a changed rule, a platform investment, focused enablement, or a conscious decision to retain the current approach.

The useful question is no longer how many findings governance produces.

It is whether those findings change the way an organization designs rules, supports teams, and makes its next decision.